This PR also aligns with the terminology used in W3C, where:

issuer's make claims about subjects.

W3C requires additional structure for the identifiers of issuers and subjects, they need to be https://www.w3.org/TR/json-ld11/#node-identifiers

JOSE and COSE do not restrict iss and sub like this, they are both string or URI.... just like feed.

• https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1

• https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.2

• https://datatracker.ietf.org/doc/html/rfc8392#section-3.1.1

• https://datatracker.ietf.org/doc/html/rfc8392#section-3.1.2

I don't see why we would invent a new label for the "identifier which the statements are in relation to", when we already have iss and sub.

The reason to have a new label is to avoid conflating it with something it isn't. Or at least something that it only imperfectly reflects.

As a trusted service implementor interested in making strong and clear assertions about completeness and non-equivocation over a series of statements, what do I do if I also see 'exp' or 'iat' in the context of 'iss' and 'sub' ? When I read a standard, from the perspective of a TS implementor again, that mentions just iss, and sub do I get to assume that I will never deal with those ?

If those are not permitted how is this actually a CWT ?

These things possibly have answers but I don't think my confusion will be an isolated one. What I would really like to see for feed id is wording like this:

Trusted Services MUST treat the feed id as an opaque series of bytes.
 Issuers MAY define encoding appropriate for their domain for the benefit
 of relying parties. Completeness and non-equivocation guarantees MUST 
only be defined in terms of the opaque array of bytes comprising the feed id

I believe that permits issuers and relying parties full flexibility of expression in the context of a very clearly articulated series of statements.

In otherwords, if we use 'sub' but define it that way, I don't see how it really is anything to do with 8392.

And this would imply the restoration of DID. So we continue to have both

If those are not permitted how is this actually a CWT ?

Signed statements are not CWTs, unless the payload content type is a CBOR map that uses registered claim names.

You can use CWT Claims in headers for payload that are xml files, this was discussed on the related draft, in the mailing list discussion I linked.

sub as a arbitrary text or feed as arbitrary text are equivalent.

The only reason not to use sub would be that you have a well defined relationship between sub and feed and iss where you need all 3 to accomplish something... AFAIK, we don't have that.

Signed statements are not CWTs, unless the payload content type is a CBOR map that uses registered claim names.

Ok, in that case, what is the TS expected to do ? I mean, it seems to force the TS to take account of the content type when before it did not ?

Ok, in that case, what is the TS expected to do ? I mean, it seems to force the TS to take account of the content type when before it did not ?

The TS has a registration policy that answers this question.

content type has always been a parameter the TS might use to deny a registration, for example, my TS might accept XML SBOMs and reject JSON ones, or vice versa.

Regardless of how you structure the info in a protected header, the registration policy and the architecture document have to make this clear.

It seems easier to make it clear, by reusing other specs, that provide context for implementers.

Aligning with existing specs is 💯 part of the SCITT Charter.
Looking a CWT Subect

The "sub" (subject) claim identifies the principal that is the
subject of the JWT. The claims in a JWT are normally statements
about the subject. The subject value MUST either be scoped to be
locally unique in the context of the issuer or be globally unique.
The processing of this claim is generally application specific. The
"sub" value is a case-sensitive string containing a StringOrURI
value. Use of this claim is OPTIONAL.

This covers a few things we've discussed, such as:

• case-sensitivity - which I personally find frustrating as someone trying to differentiate the difference between a123 and A123 is just creating a future frustration point for users that get confused why a query for one fails to find the other. However, specifying this is fine, and best practice would be to lowercase all ids- but I digress 🙄
• StringOrURI value covers the various ways an issuer may choose to represent their Artifact Feed identifier.

The thing I'd like to test with this discussion is whether two or more parties can make statements about the same artifact.

1. Wabbit Networks (the identity) releases their net-monitor v1 software (the Artifact)
2. Wabbit Networks publishes a Signed Statement using a "sub": "wabbitnetworks-netmonv3linux and "iss":="wabbitnetworks" on their scitt.wabbit-networks.io service.
3. Wabbit Networks has an auditor publish a signed statement: "sub": "wabbitnetworks-netmonv3linux and "iss":="coyote-security" on the same scitt.wabbit-networks.io service.
4. Cosmic security, Mitre and other independent publishers make statements about the same Artifact
   • "sub": "wabbitnetworks-netmonv3linux and "iss":="cosmicsecurity" on their scitt.cosmic-security.io service.
   • "sub": "wabbitnetworks-netmonv3linux and "iss":="mitre" on their scitt.mitre.org service.

As a consumer, ACME Rockets can

• query the scitt.wabbit-networks.io service, to get statements associated with the net-monitor v1 software package.
• query scitt.mitre.org for any public statements, using "sub": "wabbitnetworks-netmonv3linux as the means to find statements from Mitre for the Wabbit Networks, net-monitor v1 software.
• optionally query scitt.cosmic-security.io as they specialize in aerospace software, providing deeper insights for the specific aerospace vertical.

ACME Rockets (the consumer) can choose to trust the statements because they trust the independent identities making statements. Which endpoints they query is up to them. They could equally choose to NOT trust Coyote Security, (because who trusts the Coyote), or because they're not tailored to the unique needs Cosmic Security addresses.

Can subject be used to independently identify a collection of statements about an artifact, independently from the issuer, and consistent across SCITT Transparency Service Instances?

Ok, so I think I understand where this PR is trying to go. With respect I just don't agree with what I understand of its intent :-)

Is there something you can’t achieve where the CWT is just binary encoded in the feed id ? Provided everyone agrees the envelope feed id is an opaque string nobody needs to refer to the combination of other standards and specific reg policies to get base line confidence over the context for a series of statements.

I beleive having any structure in the feed id will gaurantee divergent and incompatible combinations of TS, issuer, series-of-statements. In particular, regarding the re-use of 'sub', I base this assertion on significant practical exposure to iss/sub in the context of identity providers & JWT's.

If we go the structured road we will lose the opportunity to define a single universal means to identify a complete series of statements in the envelope of the statement.

With a single property, defined as an opaque byte string, I believe we will get a simplicity that is enabling rather than limiting: On top of that base, richer interpretations can be built for TS's and issuers that wish to be mutualy content aware. And all TS implementations can guarantee a base level of utility before considering added value.

Yet consumers of those same feeds, regardless of origin, will still enjoy the base line ability to correlate the series of statements and demonstrate completeness and so on.

It seems easier to make it clear, by reusing other specs, that provide context for implementers.

Speaking as a prospective implementor I feel the opposite.

Can subject be used to independently identify a collection of statements about an artifact, independently from the issuer, and consistent across SCITT Transparency Service Instances?

Provided that its value is opaque to the TS for the purposes of defining the complete series, yes I believe so. And very much think this is a good thing to aim for.

That is my stall set out as clearly as I can make it :-)

I left some comments in #104 related to this. tl;dr: I agree with @robinbryce that a feed defines an unbounded sequence of statements made for the same purpose.

Obviously, any tag can be reused to mean anything you like. We can declare that sub means feed. That may require significant documentation to dissuade people from putting the a subject into sub instead.

Do I understand that the intention is to not put iss at the top level, but to embed it in CWT_claims ? Is the goal there for existing CWT relying parties to accept these?

Fixes #11